The latest updates on your projects. Learn more about Vercel for Git ↗︎

Yes, even I use this cloudflare workers and i had to add a patch everytime to replace got with fetch.

Really great PR @remorses. Much appreciated 🙏

My main hesitancy here is that the notion API can be pretty flaky at times, and got includes some really nice, non-trivial retry logic by default. I'm worried that existing use cases would become less stable with this change.

Maybe we could allow for the user to pass in their own fetch implementation to the client constructor?

I'd still like got to be usable without any additional work on the user's part. Maybe we could move it to an optional peer dependency and try conditionally importing it if it's available? If not, then we fallback to the fetch logic in this PR?

What if we move the retry logic inside the fetch method? The user could then pass something like fetchOptions: {retry: 3}

I've finally had a chance to revisit this while trying to get notion-client to work with the new Vercel edge runtime.

The main issue I'm running into is that including node-fetch anywhere in the bundle (even conditionally imported) means that it doesn't work on non-node.js runtimes such as Vercel's edge runtime. I haven't tried with CF workers, but if it works there, then I'd guess the difference is Vercel's eager bundling optimizations.

Either way, I'd love to support this use case for notion-client, but am not sure of how to proceed aside from having the user pass in a fetch implementation which is kind of poor DX.

Resolved in #394